home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text0624.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  3.4 KB  |  68 lines
  1. > Bertrand is designig Charater Specification which seems to be more that 
  2. > just that even at the moment. I think it will be smart to desing 
  3. > specification for BMW files (BadMoodWorld=analogs to WAD) in parallel 
  4. > with the BM engine, to be sure that is finished (or nearly) when engine 
  5. > will be ready.
  6.  
  7. Yes, right. Here are my suggestions about that:
  8. - It should be as compatible as possible with WADs. At least, it should be
  9. easy to convert WADs to BMWs. The specs of BMWs should contain all object
  10. types that WADs contain. But this is obvious.
  11. - It should be compatible with the charspecs. This is also obvious. Of
  12. course, if some imperative requirement about the BMW should oblige me to
  13. modify the charspecs, I'm ready to do so.
  14. - They should be evolutive, that is, we should be able to put new
  15. potentialities in while keeping it compatible with former versions.
  16. - It should be able to implement new possibilities with modules included
  17. in BMWs. That is, some vectors, variables and entry points of the engine
  18. should be available and modifyable by bits of code inside the BMW file.
  19. This way, one could imagine that a BMW could contain new features like a
  20. different AI, flying devices, etc. or even (if possible), modifications of
  21. some drawing routines, within some limits. This way, one could perhaps
  22. include in a BMW new kinds of enemies that are drawn in 3D by redirecting
  23. the sprite drawing routine. Why not?
  24.  
  25. I'm seriously thinking of doing a PC version of Bad Mood. This could look
  26. like a very stupid idea because Doom exists for PC. But it is not for the
  27. following reasons:
  28. - Bad Mood will be superior to any Doom-like game. Not technically, but
  29. potentially: even though the engine will be inferior to those of Quake or
  30. Duke 3D (or even Dark forces, which enables for some textured 3D objects),
  31. it is potentially richer from a gameplay point of vue: it will allow for
  32. very different kinds of games (kill'em all, role playing, etc.).
  33. - It enables us NOT TO CARE about compatibility of communication protocols
  34. and artificial intelligence: if we want to play doom in network between a
  35. PC and a falcon, we would just have to launch BM on both machines, and
  36. they will be compatible.
  37. - I have a falcon and a PC.
  38.  
  39. This, of course, would require a few adjustments. For example, bits of
  40. code inside characters and BMWs are a big problem. The solution I've
  41. imagined is the following:
  42. When a bit of code is necessary, it can be implemented in different ways.
  43. First, a script version should always be available. In some cases, this
  44. script could be a limited version just here for intermachine
  45. compatibility.
  46. Second, already compiled versions for different machines could, or could
  47. not be included.
  48. If the compiled version for your machine is not available, it is
  49. automatically generated (and stored, on demand) from the script. If it
  50. already exists, it is used.
  51. This enables for automatic compatibility: we can make an amiga or mac or
  52. ZX81 (not) version and use all BMWs and chars without modification.
  53. It also enables to develop versions of bits of code optimized for a given
  54. machine.
  55.  
  56. I'll update the charspecs in this direction as soon as I have some time.
  57.  
  58. What do the programmers think of this?
  59.  
  60.  
  61. Feedback welcome.
  62.  
  63. PS. Did I tell you you're a genius, Doug? Well, you are. Flattery? No.
  64. Realism.
  65. PPS. I saw Running yesterday. A few glitches, but quite nice and fast
  66. anyway. Too bad all the graphs are ripped from doom and Duke 3D.
  67.  
  68.